The release runner groups are org-level and shared, but the script assumed a
single consumer: it computed a desired allow-list from pytorch/pytorch and
PATCHed selected_workflows to exactly that set. Pointing a second repository at
the same groups would have had each run remove the other's entries, so the two
would fight on every release.

Reconcile only the entries prefixed with the target repo and carry the rest
through untouched. reconcile_repo_access already added without removing, so it
needed no change beyond taking the repo for its log lines.

--repo selects the target, defaulting to pytorch/pytorch so the existing caller
is unaffected. The version anchor is the one part that cannot be shared:
pytorch/pytorch reads CURRENT_CANDIDATE_VERSION from generate_binary_build_matrix,
which other repos do not publish, so they anchor on their newest protected
release/X.Y branch instead. Reading a version file would be wrong for repos whose
main carries the next dev version -- executorch's version.txt says 1.6.0 while
its newest branch is release/1.5.

Tests cover the scoping (other repos' entries survive, a stale entry for the
target is still replaced, pytorch/executorch-examples is not mistaken for
pytorch/executorch, an empty desired set still refuses to write) and the anchor.

For pytorch/executorch#22753.

The release runner groups are org-level and shared, but the script assumed a
single consumer: it computed a desired allow-list from pytorch/pytorch and
PATCHed selected_workflows to exactly that set. Pointing a second repository at
the same groups would have had each run remove the other's entries, so the two
would fight on every release.

Reconcile only the entries prefixed with the target repo and carry the rest
through untouched. reconcile_repo_access already added without removing, so it
needed no change beyond taking the repo for its log lines.

--repo selects the target, defaulting to pytorch/pytorch so the existing caller
is unaffected. The version anchor is the one part that cannot be shared:
pytorch/pytorch reads CURRENT_CANDIDATE_VERSION from generate_binary_build_matrix,
which other repos do not publish, so they anchor on their newest protected
release/X.Y branch instead.

For pytorch/executorch#22753.

Same shape as pytorch/executorch#22753: _select-release-runner.yml is the single
place the labels are named, and the callers pass its outputs to
build_wheels_linux.yml. Release-isolated mt-rel-l-* on the refs these workflows
publish from (nightly, main, release/* and the v* candidate tags), regular
mt-l-* everywhere else including pull requests. No path returns an EC2 label.

    x86_64  cpu/rocm/xpu  mt-l-x86iavx512-8-64      mt-rel-l-x86iavx512-44-340
    x86_64  cuda          mt-l-x86aavx2-29-113-a10g mt-rel-l-x86aavx2-29-113-l4
    aarch64 any           mt-l-arm64g4-16-62        mt-rel-l-arm64g3-44-340

The x86 matrix mixes four CPU rows (cpu, rocm10_0, rocm7_14, xpu) with three
cuda ones, and a single runner override cannot express that: it either puts the
CPU builds on a GPU runner or takes the device away from the cuda rows, whose
smoke test guards its CUDA checks with torch.cuda.is_available() and so skips
them silently. pytorch/test-infra#8789 adds a runner-gpu input for exactly this,
applied to the cuda rows only, so the split is expressed by the caller and the
per-row selection stays in the shared workflow rather than in a script here.

aarch64 needs only the one label: OSDC has no arm64 GPU runner, which matches
today, since its cuda rows already build on an m7g box with no device. The rocm
rows build ROCm wheels on an ordinary CPU builder and need no AMD hardware.

Depends on pytorch/test-infra#8789 for runner-gpu, and because without it
build_wheels_linux.yml cannot run on an OSDC pod at all.

Authored with Claude Code.

The release runner groups are org-level and shared, but the script
assumed a single consumer: it computed a desired allow-list from
`pytorch/pytorch` and PATCHed `selected_workflows` to exactly that set.
Pointing a second repository at the same groups would have had each run
remove the other's entries, so the two would fight on every release.

Now it reconciles only the entries prefixed with the target repo and
carries the rest through untouched. `reconcile_repo_access` already
added without removing, so it needed no change beyond taking the repo
for its log lines.

`--repo` selects the target, defaulting to `pytorch/pytorch`, so the
existing caller is unaffected. The version anchor is the one part that
cannot be shared: `pytorch/pytorch` reads `CURRENT_CANDIDATE_VERSION`
from `generate_binary_build_matrix`, which other repos do not publish,
so they anchor on their newest protected `release/X.Y` branch instead.
Reading a version file would be wrong for repos whose main carries the
next dev version — executorch's `version.txt` says `1.6.0` while its
newest branch is `release/1.5`.

Tests: 31 pass. New coverage for the scoping (other repos' entries
survive, a stale entry for the target is still replaced,
`pytorch/executorch-examples` is not mistaken for `pytorch/executorch`,
an empty desired set still refuses to write) and for the anchor.

For pytorch/executorch#22753.